The resource reservation protocol (RSVP, Resource Reservation Protocol) is a control protocol on a network, which is used for performing resource reservation on each node of a path. The RSVP works in a transmission layer, but does not participate in application data transfer. The RSVP supports distribution of a multi-protocol label switching (MPLS, Multi-Protocol Label Switching) label after being extended, and carries resource reservation information at the same time when transferring a label binding message, where the extended RSVP is referred to as a resource reservation protocol-traffic engineering (RSVP-TE, Resource Reservation Protocol-traffic Engineering).
A label switched path (LSP, Label Switched Path) established by adopting the RSVP-TE has a resource reservation function, a label switching router (LSR, Label Switching Router) along the path may distribute certain resources to the LSP, so as to guarantee a service transferred on the LSP. When establishing the LSP, the RSVP-TE mainly depends on two message types, a path (Path) message and a resv (Resv) message. RSVP-TE extension is mainly to add a new object in the Path message and Resv message of the RSVP-TE, and in addition to that the newly added object may carry the label binding information, the newly added object may also carry restriction information in routing the LSR along the path, such as a bandwidth, so as to support a function that the LSP constrains a routing.
The LSP established by adopting the RSVP-TE has the resource reservation function, the LSR (herein after referred to as node for short) along the path may distribute certain resources to the LSP, so as to guarantee the service transferred on the LSP. For RSVP message processing, a standard RSVP processing process is followed: an ingress (Ingress) node of the LSR generates a Path message for a session, and forwards along nodes on the LSP until forwarding to an egress (Egress) node; and after receiving the Path message, the egress node generates a Resv message and returns the Resv message to the ingress node, and in the returning process, the Resv message performs the label distribution and resource reservation on the nodes along the LSP.
At present, under the background of packet data traffic being increasingly large, some multi-path technologies emerge, such as an equal-cost multi-path routing (ECMP, Equal-Cost Multi-Path Routing) technology and a link aggregation group (LAG, Link Aggregation Group) technology.
At present, an MPLS network supports the multi-path technologies such as the ECMP and the LAG, which is widely deployed. The deployment of a multi-path such as the ECMP and the LAG, may, on one hand, provide high bandwidth and path protection, and on the other hand, existence of the multi-path also introduces a certain negative effect: a disorder is caused to packets forwarded through different paths. As the service (especially some real-time services) has a higher and higher demand for quality of service, how to make full use of advantages of the multi-path technologies such as the ECMP and the LAG and avoid a problem brought about by the multi-path technologies are problems that the Internet engineering task force (IETF, Internet Engineering Task Force) concerns about and hopes to solve at present.
In the prior art, to solve the foregoing problem, flow label application is introduced: on the ingress node of the LSP, different service flows are distributed and encapsulated with a flow label, where the service flows may be divided through related information of a data packet header. A flow label is located in a bottom layer of a label stack, the label is invisible in path forwarding, and on a load distribution node (a node before branching) of the multi-path such as the ECMP or the LAG, information of the flow label is used as a parameter of a path calculation (generally a hash algorithm is used), so as to find a suitable equal-cost path link for different service flows to perform load sharing. The introduction of the flow label may accurately forward packets belonging to the same flow by selecting the same path, so as to avoid the disorder of the packets belonging to the same flow.
Because the label-based load sharing carries the flow label in the data packet, a conventional MPLS label stack is changed, and an egress router of the network has to be able to identify and process the flow label, which demands that a special flow is divided and a load sharing mechanism is negotiated between the ingress node and the egress node of an MPLS-based LSP service. In the case of no negotiation mechanism, unnecessary protocol overhead and incorrect processing may be caused because the node does not identify the flow label, so a label-based load sharing mechanism cannot be used without negotiation.